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Description 

[0001] The recent rapid growth of information appli- 
cations on international public packet-switched compu- 
ter networks such as the Internet suggests that public 
computer networks have the potential to establish a new 
kind of open marketplace for goods and services. Such 
a marketplace could be created with a network sales 
system that comprises a plurality of buyer and merchant 
computers, means for the users of the buyer computers 
to display digital advertisements from the merchant 
computers, and means for the users to purchase prod- 
ucts described by the advertisements. 
[0002] A network based sales system will need to al- 
low users to preview products at little or no cost ; and will 
need to make a large number of product advertisements 
available in a convenient manner. In addition, the shop- 
ping system will need to include easy-to-use facilities 
for a user to purchase desired products using a mer- 
chant independent payment method. In addition the net- 
work sales will need to allow new buyers and merchants 
to enter the market. 

[0003] A central requirement for a marketplace is a 
payment mechanism, but at present no merchant inde- 
pendent payment mechanism is available for computer 
networks that permits users to utilize conventional finan- 
cial instruments such as credit cards, debit cards, and 
demand deposit account balances. We expect that both 
retail payment and wholesale payment mechanisms will 
be required for networks, with consumers using the re- 
tail mechanism for modest size purchases, and institu- 
tions using the wholesale mechanism for performing 
settlement between trading partners. For wide accept- 
ance the retail mechanism will need to be a logical ev- 
olution of existing credit-card, debit-card, and Automat- 
ed Clearing House facilities, while for acceptance the 
wholesale mechanism will need to be an evolved ver- 
sion of corporate electronic funds transfer. 
[0004] US 4,799,156 discloses a system for interac- 
tive on-line electronic communications and processing 
of business transactions between a plurality of different 
types of independent users including a plurality of sell- 
ers, and a plurality of buyers, as well as financial insti- 
tutions. Using the system, a buyer is able to instruct its 
bank to pay a bill to a distributor or another financial in- 
stitution. 

[0005] US 5,025,373 discloses a portable personal 
banking system which utilizes an encryption algorithm 
to securely transmit data between a host bank computer 
and a personal banking terminal. 
[0006] According to one aspect of the present inven- 
tion, there is provided a network based payment system 
having the features of claim 1 . According to another as- 
pect of the invention, there is provided a method of using 
a network based payment system as recited in claim 8. 
[0007] A preferred feature of the invention is to pro- 
vide a network based payment system that will authorize 
payment orders and remove part of the risk of fraud from 



merchants. 

[0008] An unavoidable property of public computer 
networks is that they are comprised of switching, trans- 
mission, and host computer components controlled by 

5 many individuals and organizations. Thus it is impossi- 
ble for a network based payment system to depend up- 
on a specified minimum required degree of software, 
hardware, and physical security for all of the compo- 
nents in a public network. For example, secret keys 

10 stored in a given user's personal computer can be com- 
promised, switches can be tempered with to redirect 
traffic, and transmission facilities can be intercepted and 
manipulated. 

[0009] The risk of performing retail payment in a pub- 
's He network is compounded by statutes that make a pay- 
ment system operator in part liable for the security laps- 
es of its users. Existing Federal statutes in the United 
States, including the Electronic Funds Transfer Act and 
the Consumer Credit Protection Act, require the opera- 
te tor of a payment mechanism to limit consumer liability 
in many cases. Payment system operators may have 
other fiduciary responsibilities for wholesale transac- 
tions. Similar responsibilities exist in other countries for 
retail and wholesale transactions. 
25 [0010] In existing credit card payment systems, a 
credit card's issuing bank takes on the fraud risk asso- 
ciated with misuse of the card when a merchant follows 
established card acceptance protocols. Acceptance 
protocols can include verifying a card holder's signature 
30 on the back of their card and obtaining authorization for 
payments over a certain value. However, in network 
based commerce a merchant can not physically exam- 
ine a purchasers credit card, and thus the fraud risk may 
revert to the merchant in so called "card not present" 
35 transactions. Many merchants can not qualify to take 
this risk because of their limited financial resources. 
Thus the invention is important to allow many merchants 
to participate in network based commerce. 
[0011] Further preferred features of the invention in- 
40 elude utilizing existing financial instruments such as 
credit cards, debit cards, and demand deposit accounts 
for merchant payments. 

[0012] Existing network-based payment systems do 
not connect to the financial system for authorization and 

45 are not compatible with conventional financial instru- 
ments. Existing network based payment systems in- 
clude the Simple Network Payment Protocol [Dukach, 
S., SNPP: A Simple Network Payment Protocol, MIT 
Laboratory for Computer Science, Cambridge, MA, 

50 1993.], Sirbu's Internet Billing Server [Sirbu, M. A., In- 
ternet Billing Service Design and Prototype Implemen- 
tation, Information Networking Program, Carnegie-Mel- 
lon University, 1993], and NetCash [Medvinsy, G., and 
Newman, B. C, NetCash: A Design for Practical Elec- 

55 tronic Currency on the Internet, Proc. 1 st ACM Conf . on 
Comp. and Comm. Security, November, 1993]. 
[0013] A further preferred feature of the invention is 
to allow users in an untrusted network environment to 
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use conventional financial instruments without requiring 
modification to existing financial system networks. 
[0014] The following definitions apply to the present 
invention. A principal is a person, company, institution, 
or other entity that is authorized to transact business as 
part of a network payment system. A payment order de- 
scribes the identity of a sender, a payment amount, a 
beneficiary, and a sender unique n-once. A sender is a 
principal making a payment. A beneficiary is a principal 
to be paid by the payment system. A sender unique 
nonce is an identifier that is used only once by a given 
sender. An example of sender unique nonces are 
unique timestamps. An external account is an account 
that can be used to settle a payment order for either a 
sender or a beneficiary in the external financial system. 
Examples of external accounts include demand deposit 
accounts and credit card accounts. An external device 
is a physical object that is kept in the possession of a 
user for the purpose of identifying the user. 
[0015] A network based payment system is a service 
that authorizes and executes digital payment orders that 
are backed by external accounts. A payment system au- 
thenticates a payment order, checks for sufficient funds 
or credit and then originates funds transfer transactions 
to carry out the payment order. A payment system ac- 
knowledges acceptance or rejection of a payment order. 
More than one payment system may exist on a given 
network, and a given payment system may operate on 
more than one host to increase its reliability, availability 
and performance. An authenticator is a digital value that 
is appended to a payment order and becomes part of 
the payment order that authenticates the payment order 
as genuine. 

[0016] The invention will now be described, by way of 
example, with reference to the accompanying drawings 
in which: 

Figure 1 is a block diagram of a typical network 
based sales system; 

Figure 2 is a screen snapshot of a buyer computer 
display of an overview page from a merchant com- 
puter; 

Figure 3 is a screen snapshot of a buyer computer 
display of a page of digital advertisements from a 
merchant computer; 

Figure 4 is a screen snapshot of a buyer computer 

display of an account query page; 

Figure 5 is a screen snapshot of a buyer computer 

display of a fulfillment page; 

Figure 6 is a flow chart illustrating the processing of 

a sale between a buyer computer and a merchant 

computer; 

Figure 7 is a flow chart illustrating the alternate 
processing of payment order means for obtaining 
missing payment information; 
Figure 8 is a screen snapshot of a buyer computer 
display of an overview page from a merchant com- 
puter that contains a query input by the user; 



Figure 9 is a screen snapshot of a buyer computer 
display of digital advertisements in response to a 
user's query: 

Figure 1 0 is a screen snapshot of a buyer computer 
5 screen of a purchase confirmation; 

Figure 11 is a screen snapshot of a buyer display 

of a fulfillment page like Figure 5; 

Figure 12 is a flow chart illustrating an alternate 

processing of a sale between a buyer computer and 
10 a merchant computer where a payment order is pre- 

authorized; 

Figure 13 is a block diagram of a typical network 
based payment system in accordance with the in- 
vention: 

15 Figure 14 is a flow chart illustrating the authentica- 
tion, authorization, and settlement of a payment or- 
der; 

Figure 15 is a flow chart illustrating an alternate 
processing of the authentication and verification of 
20 a payment order where transaction identifiers are 
used; and 

Figure 16 is a flow chart illustrating an alternate 
processing of the authorization of a payment order 
where real-time approval from the financial author- 
25 ization network may not be obtained. 

[0017] A network based sales system 200 as shown 
in Figure 1 employs a network 67 to interconnect a plu- 
rality of buyer computers 61 and 62, merchant comput- 

30 ers 63 and 64, each merchant computer with respective 
digital advertisement databases 65 and 66, and a pay- 
ment computer 68. A user of the system employs a buy- 
er computer to retrieve advertisements from the mer- 
chant computers, and to purchase goods of interest. A 

35 payment computer is used to authorize a purchase 
transaction. 

[0018] A digital advertisement includes a product de- 
scription and a price. In digital advertisement database 
65 prices and descriptions may be stored separately, 

40 and one price may apply to many product descriptions. 
[0019] In an alternate embodiment, the network 
based sales system further includes external devices 
that are kept in the possession of users so that the users 
can authenticate themselves when they use a buyer 

45 computer. 

[0020] The software architecture underlying the par- 
ticular preferred embodiment is based upon the hyper- 
text conventions of the World Wide Web. A document is 
defined to be any type of digital data broadly construed, 

50 such as multimedia documents that include text, audio, 
and video, and documents that contain programs. 
[0021] Figure 2 shows an overview screen that has 
been retrieved from a merchant computer by a buyer 
computer and displayed by the buyer computer. It in- 

55 eludes links 1 , 2, and 3 that when activated by a user 
cause the buyer's computer to take specified actions. In 
the case of link 1, the document shown in Figure 3 is 
retrieved from a merchant computer and displayed. In 
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the case of link 2, a short audio segment is retrieved 
from a merchant computer and played. In the case of 
link 3 S the query that can be entered into the query dialog 
box 4 is sent to a merchant computer, and a document 
is retrieved from the merchant computer and displayed. 5 
[0022] Figure 3 shows a document that contains three 
digital advertisements. The digital advertisements have 
been retrieved from the merchant computer after the ac- 
tivation of link 1 . The merchant computer may set the 
prices contained in the advertisements based on the the n 
identity of the user as determined, for example, by the 
network address of the requesting buyer computer. The 
document includes links 5, 6, and 7 that are used to pur- 
chase the products described by the advertisements. 
For example, if link 5 is activated the missing payment n 
information document shown in Figure 4 is retrieved 
from the merchant computer and displayed. 
[0023] Figure 4 is a missing payment information doc- 
ument that is used to gather user account information 
for the requested purchase in an HTML form. Radio but- 20 
tons 8, 9, 10, 11 , 12 are used to select a means of pay- 
ment, dialog box 13 is used to enter an account number, 
dialog box 14 is used to enter an optional authenticator 
for the account, purchase button 15 is used to send the 
account information to the merchant computer and pro- 25 
ceed with the purchase, link 1 6 is used to abort the pur- 
chase and return to the document shown in Figure 2, 
and dialog box 17 is used to enter optional user infor- 
mation that is associated with the purchase and ulti- 
mately used by a financial institution as part of a textual 30 
billing identifier for the purchase transaction. If provided, 
this additional information is included in the payment or- 
der for the purchase. 

[0024] Figure 5 is a fulf illment document 1 8 that is pro- 
duced once valid account information is provided to the 35 
missing payment information document in Figure 4 and 
purchase button 15 is activated. 
[0025] Figure 6 is a flowchart that more fully describes 
the information flow in the purchase transaction shown 
in Figures 2 to 5. An initial user inquiry 1 9 from activating 40 
link 1 results in the HTTP request 20 for a specific doc- 
ument with a specified URL. The URL specifies the 
name of the merchant computer. The merchant compu- 
ter retrieves the document given the URL at 21 , and re- 
turns it to the buyer computer at 22. The buyer computer *5 
displays the resulting HTML document at 23. When the 
user activates link 5, an HTTP request 25 is sent to the 
merchant computer requesting the document. 
[0026] In an alternate embodiment, document 22 is 
executed at 23 as a program. A program is defined as so 
a set of instructions that can exhibit conditional behavior 
based upon user actions or the environment of the buyer 
computer. As is known to those skilled in the art, there 
are many techniques for representing programs as data. 
The program can be interpreted or it can be directly ex- 55 
ecuted by the buyer computer. The program when exe- 
cuted will cause the buyer computer to interact with the 
user leading to the user purchase request 24, and the 



purchase message 25. 

[0027] The merchant computer then attempts to con- 
struct a payment order at 26 using the information it has 
gathered about the user. The buyer computer may have 
previously supplied certain credentials using fill out 
forms or other account identification means such as pro- 
viding the network address of the buyer computer in the 
normal course of communication. If the merchant com- 
puter is able to construct a complete payment order at 
26 the payment order is sent to a payment computer for 
authorization at 27. If a payment order can be construct- 
ed, processing continues at 28. 
[0028] Alternatively, the buyer computer may. con- 
struct the payment order at 24 and send it to the mer- 
chant computer at 25. In this case, the payment order 
assembly steps at 26, at the merchant computer, may 
only need to forward the payment order from the buyer 
computer. 

[0029] A payment order includes user account infor- 
mation, merchant account information, an amount, and 
a nonce identifier that has not been previously used for 
the same user account. Variations of payment orders 
can be constructed, including payment orders that spec- 
ify user or merchant identifiers in place of account infor- 
mation, payment orders that specify a valid time period, 
payment orders that specify foreign currencies, and 
payment orders that include comment strings. Part of 
the process of constructing a payment order is creating 
a corresponding authenticator using one of the authen- 
ticator methods described below. 
[0030] In the illustrated embodiment of Figures 3 and 
4, the merchant computer does not have sufficient infor- 
mation to construct a payment order at 26 and thus at 
33 (Figure 7) constructs and returns a missing payment 
information document in response to request 25. Oper- 
ation 33 includes in the constructed document appropri- 
ate form fields based on what information the merchant 
computer has already collected from the user. The doc- 
ument is returned to the buyer computer at 34 and is 
displayed at 35. When the user presses the purchase 
button 15, the contents of the form are transmitted to the 
merchant computer, at 36, to a specific URL name, us- 
ing an HTTP request. Based on the supplied form fields, 
the merchant computer constructs a complete payment 
order. Alternatively, the buyer computer may construct 
the payment order at 35 and send it to the merchant 
computer as part of step 36. In this case, the payment 
order assembly steps 37 at the merchant computer sim- 
ply passes on the payment order from the buyer com- 
puter. The payment order is sent to the payment com- 
puter in a message at 38. 

[0031] In either case, the flowchart continues in Fig- 
ure 6 where the payment computer checks the authori- 
zation of the payment order at 28. If the payment system 
authorizes the request, an authorization message at 29 
is returned to the merchant computer, and the merchant 
computer checks at 30 that the authorization message 
came from the payment computer using the authentica- 
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tor mechanism described below. Assuming that the au- 
thorization message is valid s the merchant computer 
performs fulfillment at 30, returning the purchased prod- 
uct in response at 31. In our example in Figure 5 the 
response at 31 is document 1 8 that was the logical tar- 
get of link 5. If the payment system does not authorize 
the payment order then response 31 is a rejection of the 
user's purchase request. 

[0032] In an alternate embodiment, step 30 can en- 
crypt the document using a key that is known to the buy- 
er computer. As is known to those skilled in the art, the 
key can be communicated to the merchant computer us- 
ing convention key distribution protocols. In this manner 
the document will be protected from disclosure to other 
users. 

[0033] The fulfillment step at 30 can alternatively 
schedule a physical product to be shipped via ordinary 
mail or other means. This can be accomplished by up- 
dating a fulfillment request database or by sending a 
message to a shipping system. In this case the response 
at 31 is a confirmation that the product has been sched- 
uled to ship. In this way the network sales system can 
implement an electronic mail order system. 
[0034] Figures 8, 9 ; 10, and 11 show a second exam- 
ple that uses query based access to digital advertise- 
ments. It is assumed that the previous example was 
used by the user immediately before at the same buyer 
computer. 

[0035] Figure 8 shows the overview screen where the 
query "movie review" has been entered into dialog box 
39. When the user activates process button 40, the mer- 
chant searches databases as described by the URL at- 
tached to button 40, and creates a response document 
as shown in Figure 9. 

[0036] Figure 9 shows digital advertisements 39, 40, 
41 , 42, 43, and 44 that were found in response to the 
query initiated by button 40. A scroll bar 45 shows that 
there are additional digital advertisements that are not 
shown. When link 46 is activated, the missing account 
information document shown in Figure 10 is returned by 
the merchant computer. 

[0037] Figure 1 0 shows that the merchant computer 
has partial information on the buyer's account. Message 
47 shows that the merchant computer already knows 
the buyer's account number. Purchase button 48 will 
send the optional user reference string in dialog box 50 
to the merchant computer described by the URL behind 
button 48 and purchase the product corresponding to 
digital advertisement 39. Cancel link 49 will return the 
user to the document shown in Figure 2. 
[0038] When purchase button 48 is activated, a doc- 
ument 51 is sent by the merchant computer and dis- 
played by the buyer computer as shown in Figure 11 . 
[0039] Figure 12 shows an alternative method of 
processing a sales transaction. In this method when the 
user requests a purchase at 52, the buyer computer 
constructs a payment order at 53 and sends it for ap- 
proval to the payment computer at 54. The payment 



computer authorizes the payment order at 55; and when 
the payment order is authorized, returns an unforgable 
certificate at 56 that the payment order is valid. Means 
of creating such unforgable certificates are described in 
5 authenticator method number one below. If at step 55 
the payment order is not authorized, a rejection mes- 
sage is sent at 56 and the sales transaction is terminat- 
ed. 

[0040] The buyer computer then proceeds at 57 to 
10 send a pre-authorized purchase request to the mer- 
chant computer. The unforgable certificate 56 is includ- 
ed in a purchase message at 57 that is sent at 58 to the 
merchant computer. Based upon the pre-authorized 
payment order the merchant computer performs fulfill- 
15 ment at 59 and returns the product at 60. In a variation, 
the merchant computer at 59 checks to ensure the pay- 
ment order has not been previously used. This can be 
accomplished by checking with a payment computer or 
maintaining a merchant computer database of previous- 
20 ly accepted payment orders. The unforgable certificate 
created at step 56 does not need to include the user 
account information. This variation is useful if the user 
wishes to make purchases and remain anonymous to 
the merchant. 

25 

A Network Based Payment System 

[0041] A network based payment system 300 as 
shown in Figure 13, employs a public packet-switched 

30 network 69 to interconnect a plurality of client computers 
70 and 71, and a plurality of payment computers such 
as 72, each payment computer having an account da- 
tabase 73, a settlement database 74, an authorized ad- 
dress database 75, a sender credential database 76, a 

35 financial system interface 77, and a real-time authoriza- 
tion interface 78. The interfaces 77 and 78 may be im- 
plemented by a single communications line. 
[0042] In an alternate embodiment, the network 
based payment system further includes external devic- 

40 es that are kept in the possession of users so that the 
users can authenticate themselves when they use a 
buyer computer. 

[0043] Account database 73 maintains temporal 
spending amounts, such as the amount spent in the cur- 

45 rent day. and also maintains temporal spending limits. 
The account database may also maintain a translation 
between principal identifiers and external account iden- 
tifiers. Settlement database 74 records committed pay- 
ment orders along with any authorization information for 

so the orders that was obtained from interface 78. Address 
database 75 maintains for each sender a list of author- 
ized buyer computer and delivery addresses. Credential 
database 76 maintains a list of credentials for principals 
and information that can be used to authenticate princi- 

55 pals. 

[0044] Figure 1 4 is a flowchart that describes the op- 
eration of the payment system. A client computer 71 
constructs a payment order at 79, and computes and 
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adds an authenticator to the payment order at 80. The 
payment order is sent at 81 to a payment computer, 
where the authenticator is verified at 82 to ensure that 
the payment order was originated by the sender it de- 
scribes. Below we present different means of imple- 
menting 80 and 82. 

[0045] If the payment order is authentic and address 
restrictions are desired, at 83, either or both of the client 
computer address or the specified delivery address can 
be checked against address database 75. If address re- 
strictions are desired and if the addresses in the pay- 
ment order are not in the database, the payment com- 
puter sends a rejection message to the client computer. 
Address database 75 specifies, for each principal, ac- 
ceptable client computer addresses and delivery ad- 
dresses. A delivery address can be a network address, 
or a street address for packaged goods. As is known in 
the art. database 75 can include wild-card specifications 
and similar techniques to reduce its size. 
[0046] For example, database 75 could contain an en- 
try for principal identifier "*@ acme.com" restricting legal 
delivery addresses to "computer: *.com", "computer: 
cmu.edu", and "surface: *, 34 Main Street, Anytown, 
USA", indicating that any user at the company Acme can 
order products to be delivered to the network address 
at Acme or the university CMU, or to anyone at 34 Main 
Street, Anytown, USA. 

[0047] If payment order address restrictions are not 
desired or have been checked, processing continues at 
84 where the payment order is checked for replay and 
temporal spending limits. Replay is checked for by mak- 
ing sure that the sender did not previously present a pay- 
ment order with the same nonce by checking an index 
of committed payment orders by nonce in settlement da- 
tabase 74. If nonces are based on time, then a payment 
order that is older than an administratively determined 
value can be rejected out of hand. Time based nonces 
or sequential nonces permit old nonces to be removed 
from the settlement database 74. If a payment order has 
been previously processed or its nonce is too old, the 
payment order computer sends a rejection message to 
the client. 

[0048] After the payment order passes the replay 
check, temporal spending limits are checked in account 
database 73. These spending limits can be applied on 
a per sender per group of senders, and per payment 
system basis to limit fraud risk. The limits can be applied 
to any duration of time, for example a maximum spend- 
ing amount per hour or per day. If the payment order 
would violate a spending limit, the payment computer 
sends a rejection message to the client. 
[0049] Once the payment order passes the temporal 
spending check at 84, a message is constructed at 85 
to check that the external account that backs the send- 
er's payment system account has adequate funds or 
credit. If the sender identifier in the payment order is not 
already an account number in the external financial sys- 
tem, it is translated into a corresponding account 



number in the external financial system using account 
database 73. A real-time authorization request mes- 
sage is sent at 86 to the external financial system over 
interface 78. If the external financial system approves 
s authorization request 86, an authorization message is 
returned at 87. If request 86 is not approved, the pay- 
ment computer sends a rejection message to the client 
at 87. 

[0050] In a variation of the above described approach, 
10 processing continues at 95 after 84. At 95 real-time au- 
thorization is only obtained when the total of a sender's 
payments since the last real-time authorization reaches 
a preset value, or the payment order is over a preset 
amount. These preset values can be optionally recorded 
'5 on a per principal basis in database 73 or can be admin- 
istratively determined for all principals. In this manner, 
the number of messages to the external financial system 
can be reduced. In addition, the payment system can 
avoid making real-time authorization requests for small 

20 payments when the risk is acceptable to the payment 
system operator. If real-time authorization is necessary, 
processing continues at 85 after 95. If real-time author- 
ization is not necessary for a request, at 1 00 the pay- 
ment order amount is added to the sender's total of pay- 

25 ments since the last real-time authorization in database 
73, and processing continues at 88. 
- [0051] In another variation after 100 a check is made 
at 1 01 in database 73 to see if a background authoriza- 
tion process should be scheduled. A background au- 

30 thorization process permits the payment computer to 
continue its normal processing while it checks with the 
financial authorization network on the sender's account. 
This mechanism can be used to limit payment system 
risk. If the background authorization fails, the account 

35 is suspended by so updating database 73. If the send- 
er's total of payments since last authorization is over a 
preset value stored in 73 then a background authoriza- 
tion process is scheduled at 102. Otherwise processing 
continues at 88. 

40 [0052] In another variation, at 95 and 101 authoriza- 
tions are obtained based on the amount spent since last 
authorization and time since last authorization. 
[0053] At 88 the payment order is committed to exe- 
cution and is recorded in settlement database 74. Re- 

45 corded with the payment order in database 74 are por- 
tions of authentication message 87 that show that the 
payment computer contacted the remote financial sys- 
tem. The amount of the payment order is added to run- 
ning temporal spending records in database 73, and an 

50 authorization message is sent to the client computer at 
90. The authorization message includes the payment 
order. In an alternate embodiment, at 90 the authoriza- 
tion message contains a truncated payment order that 
includes at least the payment order's sender and the 

55 payment order's unique nonce. 

[0054] In an alternate embodiment, the authorization 
message sent to the client at 90 includes at least one 
legal delivery address for the sender as determined from 
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database 75. 

[0055] Authorization message 90 must be transmitted 
in such a way that the client computer can be sure that 
it came from the payment computer. At 89 a payment 
system specific authenticator is added to the payment 
order. At 91 this authenticator is checked by the client 
computer. The steps at 89 are a dual of step 80, and the 
steps at 91 are a dual of step 82. The authentication 
means for steps 89 and 91 are described below. 
[0056] Finally, settlement is performed at 92 in the ex- 
ternal financial system 77 between external accounts 
that correspond to the sender and the beneficiary. If set- 
tlement is accomplished as part of real-time authoriza- 
tion at steps 86 and 87, as may occur in a real-time debit 
network, then no other steps need to be taken. If settle- 
ment is not accomplished as part of the authorization 
process, then financial system messages are sent to in- 
terface 77 to effect settlement. Depending on the exter- 
nal accounts involved, these messages may include 
electronic funds transfer messages or automated clear- 
inghouse messages. 

[0057] In an alternate embodiment, at 92 settlement 
messages are sent to reconcile net transfer balances 
between principles on a temporal basis, for example 
once a day. In this embodiment the number of settle- 
ment messages can be less than the number of pay- 
ment orders. 

[0058] According to claims 1 and 8, authenticators are 
created and checked using one of the following first, 
second or third methods. 

[0059] Fourth, fifth, sixth and seventh methods are al- 
so disclosed, which can be used by the payment com- 
puter and the client computer additionally in combina- 
tion with any of the first, second and third methods. 
[0060] In a first method for authenticators, at steps 80 
or 89, a digest of the payment order is signed by the 
sending computer using a public-key cryptographic sys- 
tem such as RSA. This signature is used as the authen- 
ticator. As is well known in the art, the signing can be 
accomplished using a private key created from a public- 
key pair, where the signing key is only known by the 
signer, and the other public key is known to the receiving 
computer. At the payment computer the public key cor- 
responding to each sender is kept in credential data- 
base 76. The private key for the payment service is also 
kept in database 76. At steps 82 or 91 , the signature of 
the received message is checked using the public key 
known to the receiving computer. 
[0061 ] In a second method for authenticators, at steps 
80 or 89, a digest of the payment order is signed by the 
sending computer with a private key cryptosystem such 
as DES. This signature is used as the authenticator. At 
the payment computer, the private key corresponding to 
each sender is kept in credential database 76. At step 
80, a digest of the payment order is signed by the client 
computer, and at step 89 a digest of the payment order 
with an added approval code is signed by the payment 
computer using the same private key. At steps 82 or 91 , 



the signature of the received message is checked using 
the shared private key. 

[0062] In a third method for authenticators, at step 80, 
the authenticator is computed by a protected device ex- 

5 ternal to the system such as a Smart-Card. A protected 
device is specifically designed to be extremely difficult 
both to replicate and to compromise. In this method, the 
payment order is communicated at 80 to a Smart-Card. 
The Smart-Card computes and signs a digest of the pay- 

10 ment order, and then communicates the signature back 
at 80 to be used as an authenticator. A Smart-Card pro- 
duced authenticator uniquely associates a payment or- 
der with its creating Smart-Card. This is accomplished 
by having the Smart-Card contain a secret key "K" that 

15 js used to create a digital signature of the payment order. 
"K" is never released outside of the Smart-card. The 
Smart-Card is designed to make it computationally in- 
feasible to compute M K" even with possession of the de- 
vice. In this method, at step 82, a signature checking 

20 key from database 76 is used to check the authenticator. 
In an alternate embodiment, a user must manually sig- 
nal their acceptance of each payment order on an input 
device that is part of the external device before the au- 
thenticator is created by the external device. 

25 [0063] In a fourth method for authenticators, for use 
with any of the first to third methods, at steps 80 or 89, 
a network address is used as an authenticator. At steps 
82 or 91 , a digest of the payment order is sent back to 
the specified network address along with a random 

30 password. The computer at the specified network ad- 
dress must then return the payment order digest along 
with the password. If the network guarantees to deliver 
messages to the proper network address, this method 
will guarantee that the user or computer at the specified 

35 network address approves of the payment order. As- 
suming that network delivery is trusted, this method can 
be used to authenticate a sender computer's network 
address in a payment order. Alternatively, electronic 
mail can be used to send such confirmation messages 

40 between a user and the payment system. 

[0064] In a fifth method for authenticators, at step 80 
for use with any of the first to third methods, the authen- 
ticator is produced by an external device that produces 
a sequence of non-predictable transaction identifiers 

45 that are device specific. The authenticator is entered by 
the user into the client computer by reading its display. 
One such device is described in U.S. Patent 4,856,062. 
According to this method, at step 91 , the authenticator 
can be checked using the sender specific fixed cede of 

50 the device which is kept in database 76. This sequence 
of steps is also shown in Figure 15 at steps 93 and 94. 
[0065] In a sixth method for authenticators, for use 
with any of the first to third methods, at step 80, the au- 
thenticator is obtained by querying the user for a trans- 

55 action identifier that is the next string from a physical list 
of one-time authorization strings. Such as list could be 
produced on a card, and the user can cross off author- 
ization strings as they are used. According to this meth- 
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od, at step 91 , the authenticator is checked against the 
next expected string from the sender using database 76. 
Database 76 can hold for each sender a list of random 
authorization strings, or can hold a sender specific se- 
cret key that was used to generate the list of authenti- 
cation strings along with how many strings have been 
used so far. This sequence of steps is also shown in 
Figure 15 at 93 and 94. 

[0066] In a seventh method for authenticate^ for use 
with any of the first to third methods, at step 80 the au- 
thenticator is a previously obtained personal identifica- 
tion number (PIN) for the user. In this method in 91 the 
authenticator is checked against the expected PIN for 
the sender using database 76. 

[0067] As will be obvious to one skilled in the art, any 
of the methods for creating authenticators can be used 
together to increase system security. For example, au- 
thenticator method six can be used to create an authen- 
ticator based on a transaction identifier, and then a pay- 
ment order including a transaction identifier can be giv- 
en a further authenticator using authenticator method 
one. In this example the resulting authenticators would 
be checked with their respective methods. 
[0068] A digest of a payment order can be created 
with an algorithm such as MD5 [R. Rivest, The MD5 
Message- Digest Algorithm, MIT Laboratory for Compu- 
ter Science, Network Working Group Request for Com- 
ments 1321]. Alternatively, a digest can be the entire 
payment order or other functions of the payment order's 
component parts. 

[0069] In addition in both the sales and payment sys- 
tems alternate authenticator techniques can be used 
such as those described by Voydock and Kent in "Se- 
curity Mechanisms in High-level Network Protocols", 
Computing Surveys Vol. 15, No. 2, June 1983. As will 
be appreciated by those skilled in the art, two-way au- 
thenticated byte-stream or remote procedure call inter- 
face connections that protect against replay can replace 
our message based authenticators. 



Claims 

1. A network based payment system (300) compris- 
ing: 



each one of the client computers (70 : 71 ) being 
programmed to construct a payment order 
specifying a payment amount to be transferred 
from a sender to a beneficiary, a nonce, a send- 
5 er identifier or account information, and a ben- 

eficiary identifier or account information, to sign 
the payment order with a digital signature of a 
digest of the payment order, the digital signa- 
ture authenticating the sender of the payment 

'0 order, the digital signature being computed 

based on a secret key, to cause the payment 
order and the digital signature to be transmitted 
to the payment computer over the public packet 
switched communications network (69), and to 

15 receive a payment order authorization mes- 

sage from the payment computer; 
the payment computer (72) being programmed 
to receive the payment order and the digital sig- 
nature, and in response thereto, to verify that 

20 said payment order originated from the sender 

of the payment order based on the received dig- 
ital signature, to check for replay to ensure that 
the sender of the payment order did not previ- 
ously present a payment order with the same 

25 nonce, to cause a message to be transmitted 

into the financial authorization network, in order 
to verify that the sender has adequate funds or 
credit, to receive an authorization from the fi- 
nancial authorization network in response to 

30 the message, to transmit a payment order au- 

thorization message to the client computer over 
the public packet switched communications 
network, to cause information pertaining to the 
payment order and authorization to be record- 

35 ed in a settlement database (74), and to cause 

a financial system network external to the pub- 
lic packet switched communications network 
(69) to transfer funds from the sender to the 
beneficiary conditioned on receipt by the pay- 

40 ment computer of the authorization from the fi- 

nancial authorization network. 

2. A network based payment system in accordance 
with claim 1, wherein the digest is the entire pay- 
^5 ment order. 



a plurality of client computers (70, 71 ); 3. 
at least one payment computer (72); 
the client computers and the payment compu- 
ter being interconnected by a public packet 50 
switched communications network (69); and 4. 
a financial authorization network (via 78) exter- 
nal to the public packet switched communica- 
tions network (69), being programmed to au- 
thorize payment of a payment amount based 55 
on an external credit card account or an exter- 
nal demand deposit account having sufficient 
credit or funds; 5. 



A network based payment system in accordance 
with claim 1 , wherein the digest is a function of com- 
ponent parts of the payment order. 

A network based payment system in accordance 
with any of claims 1 to 3, wherein the payment order 
comprises a delivery address, and wherein the pay- 
ment computer (72) is programmed to cause the de- 
livery address to be checked against a database of 
allowed delivery addresses for the sender. 

A network based payment system in accordance 
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with any preceding claim, wherein the payment 
computer (72) is programmed to cause at least one 
allowed delivery address for the sender to be deter- 
mined, and wherein the payment order authoriza- 
tion message comprises the at least one allowed s 
delivery address. 

A network based payment system in accordance 
with any preceding claim, wherein the payment or- 
der authorization message comprises an authenti- io 
cator. 

A network based payment system in accordance 
with any preceding claim, wherein the client com- 
puter (70, 71 ) is programmed to generate the digital *5 
signature using an external device, and wherein the 
payment computer (72) is programmed to verify that 
the digital signature was created using the external 
device. 

20 

A method of using a network based payment sys- 
tem (300) comprising a plurality of client computers 
(70, 71), at least one payment computer (72) inter- 
connected by a public packet switched communica- 
tions network (69), and a financial authorization net- 25 
work external to the public packet switched commu- 
nications network (69), comprising the steps of: 

constructing a payment order (79) at one of the 
client computers specifying a payment amount 30 
to be transferred from a sender to a beneficiary, 
a nonce, a sender identifier or account informa- 
tion, and a beneficiary identifier or account in- 
formation, signing (80) the payment order with 
a digital signature of a digest of the payment 35 
order, the digital signature authenticating the 
sender of the payment order and being com- 
puted based on a secret key, and causing the 
payment order and the digital signature to be 
transmitted (81 ) to the payment computer over *o 
the public packet switched communications 
network (69); 

in response to receipt of the payment order and 
the digital signature by the payment computer 
verifying (82) that the payment order originates 
from the sender of the payment order based on 
the received digital signature, checking for re- 
play (84) to ensure that the sender of the pay- 
ment order did not previously present a pay- 
ment order with the same nonce, causing a so 
message to be transmitted (86) into the finan- 
cial authorization network, in order to verify that 
the sender has adequate funds or credit; 
the financial authorization network authorizing 
payment of the payment amount based on an ss 
external credit card account or an external de- 
mand deposit account having sufficient credit 
or funds; 



receiving (87), at the payment computer, an au- 
thorization from the financial authorization net- 
work in response to the message, transmitting 
a payment order authorization message (90) 
from the payment computer to the client com- 
puter over the public packet switched commu- 
nications network, causing information pertain- 
ing to the payment order and authorization to 
be recorded in a settlement database (74), and 
causing a financial system network external to 
the public packet switched communications 
network, to transfer funds from the sender to 
the beneficiary conditioned on receipt by the 
payment computer of the authorization from the 
financial authorization network, and 
receiving the payment order authorization mes- 
sage at the client computer. 

9. A method in accordance with claim 8, wherein the 
digest is the entire payment order. 

10. A method in accordance with claim 8, wherein the 
digest is a function of component parts of the pay- 
ment order. 



Patentanspruche 

1. Netzwerkgestiitztes Zahlungssystem (300) mit: 

mehreren Klientencomputem (70 ; 71), 
wenigstens einem Zahlungscomputer (72). 

wobei die Klientencomputer und der Zah- 
lungscomputer durch ein offentliches paketvermit- 
teltes Kommunikationsnetzwerk (69) verbunden 
sind, und 

einem Finanzautorisierungsnetzwerk (via 78) 
auBerhalb des offentlichen paketvermittelten Kom- 
munikationsnetzwerks (69), das dazu programmiert 
ist, die Zahlung eines Zahlungsbetrages auf der 
Grundlage eines externen Kreditkartenkontos Oder 
eines externen Sichteinlagenkontos mit ausrei- 
chendem Kredit oder Guthaben zu autorisieren, 

wobei jeder der Klientencomputer (70, 71 ) da- 
zu programmiert ist, eine Zahlungsanweisung zu 
konstruieren, die einen von einem Absender an ei- 
nen Zahlungsempfanger zu transferierenden Zah- 
lungsbetrag, ein Augenblickswort, eine Absender- 
kennung oder -kontoinformation und eine Zah- 
lungsempfangerkennung oder -kontoinformation 
spezifiziert, die Zahlungsanweisung mit einer digi- 
talen Signatur einer Zusammenfassung der Zah- 
lungsanweisung zu signieren, welche digitale Si- 
gnatur den Absender der Zahlungsanweisung au- 
thentiziert wobei die digitale Signatur auf der Basis 
eines geheimen Schlussels berechnet wird, zu ver- 
anlassen, daf3 die Zahlungsanweisung und die di- 
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gitale Signatur uber das offentliche paketvermlttelte - 
Kommunikationsnetewerk (69) an den Zahlungs- 
computer ubermittelt werden, und eine Zahlungs- 
anweisungs-Autorisierungsnachricht vom Zah- 
lungscomputer zu empfangen, 5 

wobei der Zahlungscomputer (72) dazu pro- 
grammlert ist, die Zahlungsanweisung und die digi- 
tate Signatur zu empfangen und als Reaktion dar- 
auf anhand der empfangenen digitalen Signatur zu 
verifizieren, daB die Zahlungsanweisung vom Ab- 10 
sender der Zahlungsanweisung stammt eine Uber- 
prtifung auf Wiedergabe einer Aufzeichnung durch- 
zufuhren, urn sicherzustellen, daB der Absender 
der Zahlungsanweisung nicht f rune r eine Zahlungs- 
anweisung mit demselben Augenblickswort pra- '5 
sentiert hat : zu veranlassen, daB eine Nachricht in 
das Finanzautorisierungsnetzwerk ubermittelt wird. 
urn zu verifizieren, daB der Absender ein adaquates 
Guthaben oder Kredit hat, als Antwort auf die Nach- 
richt eine Autorisierung vom Finanzautorisierungs- 20 
netzwerk zu empfangen, eine Zahlungsanwei- 
sungs-Autorisierungsnachricht uber das offentliche 
paketvermittelte Kommunikationsnetzwerk an den 
Klientencomputer zu ubermitteln, zu veranlassen, 
daB Information uber die Zahlungsanweisung und 25 
die Autorisierung in einer Abwicklungsdatenbank 
(74) aufgezeich net wird, und, konditioniert dadurch, 
daB der Zahlungscomputer die Autorisierung vom 
Finanzautorisierungsnetzwerk empfangt, ein Fi- 
nanzsystem-Netzwerk auBerhalb des offentlichen 30 
paketvermittelten Kommunikationsnetzwerkes (69) 
zu veranlassen, Guthaben vom Absender an den 
Zahlungsempfanger zu transferieren. 

Netzwerkgestutztes Zahlungssystem nach An- 35 
spruch 1 , bei dem die Zusammenfassung die ge- 
samte Zahlungsanweisung ist. 

Netzwerkgestutztes Zahlungssystem nach An- 
spruch 1, bei dem die Zusammenfassung eine 40 
Punktion von Bestandteilen der Zahlungsanwei- 
sung ist. 

Netzwerkgestutztes Zahlungssystem nach einem 
der Anspruche 1 bis 3, bei dem die Zahlungsanwei- 45 
sung eine Zustelladresse enthalt und der Zahlungs- 
computer (72) dazu programmiert ist, zu veranlas- 
sen, daB die Zustelladresse gegen eine Datenbank 
von zulassigen Zustelladressen fur den Absender 
gepruft wird. so 

Netzwerkgestutztes Zahlungssystem nach irgend- 
einern vorstehenden Anspruch, bei dem der Zah- 
lungscomputer (72) dazu programmiert ist, zu ver- 
anlassen, daB wenigstens eine zulassige Zustell- 55 
adresse fur den Absender bestimmt wird, und die 
Zahlungsanwelsungs-Autorisierungsnachricht die 
wenigstens eine zulassige Zustelladresse enthalt. 



6. Netzwerkgestutztes Zahlungssystem nach irgend- 
einem vorstehenden Anspruch, bei dem die Zah- 
lungsanwelsungs-Autorisierungsnachricht eine Au- 
thentifizierung enthalt. 

7. Netzwerkgestutztes Zahlungssystem nach irgend- 
einem vorstehenden Anspruch, bei dem der Klien- 
tencomputer (70, 71) dazu programmiert ist, die di- 
gitate Signatur mit Hilfe einer externen Einrichtung 
zu erzeugen, und der Zahlungscomputer (72) dazu 
programmiert ist, zu verifizieren, daB die digitate Si- 
gnatur mit Hilfe der externen Einrichtung erzeugt 
wurde. 

8. Verfahren zum Gebrauch eines netzwerkgestiitzten 
Zahlungssystems (300) mitmehreren Klientencom- 
putern (70, 71), wenigstens einem durch ein offent- 
llches paketvermitteltes Kommunikationsnetzwerk 
(69) verbundenen Zahlungscomputer (72) und ei- 
nem Finanzautorisierungsnetzwerk auBerhalb des 
offentlichen paketvermittelten Kommunikations- 
netzwerkes (69), mit den Schritten: 

Konstruieren einer Zahlungsanweisung (79) an 
einem der Klientencomputer, die einen von ei- 
nem Absender an einen Zahlungsempfanger 
zu transferierenden Zahlungsbetrag, ein Au- 
genblickswort, eine Absenderkennung oder 
-kontoinformation und eine Zahlungsempfan- 
gerkennung oder -kontoinformation spezifi- 
ziert, Signieren (80) der Zahlungsanweisung 
mit einer digitalen Signatur einer Zusammen- 
fassung der Zahlungsanweisung, wobei die di- 
gitate Signatur den Absender der Zahlungsan- 
weisung authentiziert und auf der Grundlage ei- 
nes geheimen Schlussels berechnet wird, und 
Veranlassen, daB die Zahlungsanweisung und 
die digitate Signatur uber das offentliche paket- 
vermittelte Kommunikationsnetzwerk (69) an 
den Zahlungscomputer ubermittelt (81) wer- 
den, 

als Reaktion auf den Empfang der Zahlungsan- 
weisung und der digitalen Signatur durch den 
Zahlungscomputer, verifizieren (82), daB die 
Zahlungsanweisung vom Absender der Zah- 
lungsanweisung stammt, anhand der empfan- 
genen digitalen Signatur, Priifen auf Wiederga- 
be (84) einer Aufzeichnung, urn sicherzustel- 
len, daB der Absender der Zahlungsanweisung 
nicht fruher eine Zahlungsanweisung mit dem- 
selben Augenblickswort prasentiert hat, veran- 
lassen, daB eine Nachricht in das Finanzauto- 
risierungsnetzwerk ubermittelt (86) wird, umzu 
verifizieren, daB der Absender ein adaquates 
Guthaben oder Kredit hat, 

wobei das Finanzauthorisierungsnetzwerk 
die Zahlung des Zahlungsbetrages auf der Grund- 



10 



19 



EP 0 734 556 B1 



20 



lage eines externen Kreditkartenkontos oder eines 
externen Sichteinlagenkontos mit ausreichendem 
Kredit Oder Guthaben autorisiert.. 

Empfangen (87), am Zahlungscomputer, ei- 
ner Autorisierung vom Finanzauthorisierungsnetz- 5 
werk als Reaktion auf die Nachricht. Ubermitteln ei- 
ner Zahlungsanweisungs-Autorisierungsnachricht 
(90) vom Zahlungscomputer an den Klientencom- 
puter uber das offentliche paketvermittelte Kommu- 
nikationsnetzwerk. Veranlassen, daft Information 10 
uber die Zahlungsanweisung und Autorisierung in 
einer Abwicklungsdatenbank (74) aufgezeichnet 
werden : und Veranlassen eines Finanzsy- 
stem-Netzwerks auQerhalb des offentlichen paket- 
vermittelten Kommunikationsnetzwerkes, Gutha- 15 
ben vom Absender an den Zahlungsempfanger zu 
transferieren, konditioniert dadurch, daG der Zah- 
lungscomputer die Autorisierung vom Finanzauto- 
risierungsnetzwerk empfangt, und 

Empfangen der Zahlungsanweisungs-Autori- 20 
sierungsnachricht am Klienten-Computer. 

9. Verfahren nach Anspruch 8, bei dem die Zusam- 
menfassung die gesamte Zahlungsanweisung ist. 

25 

10. Verfahren nach Anspruch 8. bei dem die Zusam- 
menfassung eine Funktion von Bestandteilen der 
Zahlungsanweisung ist. 

30 

Revendications 

1 . Systeme de paiement base sur un reseau informa- 
tique (300), comprenant : 

35 

une pluralite d'ordinateurs clients (70,71), 

au moins un ordinateur de paiement (72), 

les ordinateurs clients et I'ordinateur de paie- *o 
ment etant relies entre eux par un reseau public 
de communications commute par paquets 
(69) ; et 



concemant I'expediteur et un identificateur ou 
une information de compte concernant le bene- 
ficiaire, pour signer I'ordre de paiement avec 
une signature numerique d'un abrege de I'ordre 
de paiement, la signature numerique authenti- 
fiant I'expediteur de I'ordre de paiement, la si- 
gnature numerique etant informatisee sur la ba- 
se d'une cle secrete, pour permettre la trans- 
mission de I'ordre de paiement et de la signa- 
ture num6rique a I'ordinateur de paiement sur 
le reseau public de communications commute 
par paquets (69), et pour recevoir un message 
d'autorisation d'ordre de paiement de la part de 
I'ordinateur de paiement ; 

I'ordinateur de paiement (72) etant programme 
pour recevoir I'ordre de paiement et la signatu- 
re numerique, et en reponse a cela, pour veri- 
fier que le dit ordre de paiement provient bien 
de I'expediteur de I'ordre de paiement sur la ba- 
se de la signature numerique recue, pour veri- 
fier une repetition afin de s'assurer que I'expe- 
diteur de I'ordre de paiement n'a pas presente 
anterieurement un ordre de paiement ayant le 
meme mot cree, pour provoquer la transmis- 
sion d'un message dans le reseau d'autorisa- 
tion financiere, afin de verifier que I'expediteur 
dispose de fonds ou d'un credit appropries, 
pour recevoir une autorisation de la part du re- 
seau d'autorisation financiere en reponse au 
message, pour transmettre un message 
d'autorisation d'ordre de paiement a I'ordina- 
teur client sur le reseau public de communica- 
tions commute par paquets, pour faire que Tin- 
formation appartenant a I'ordre de paiement et 
a I'autorisation soit enregistree dans une base 
de donnees de reglement (74), et pour faire 
transferer par un reseau public de communica- 
tions commute par paquets (69) des fonds de 
I'expediteur au beneficiaire sous la condition de 
la reception par I'ordinateur de paiement de 
I'autorisation provenant du reseau d'autorisa- 
tion financiere. 



un reseau d'autorisation financiere (via 78) ex- « 
terieur au reseau public de communications 
commute par paquets (69) etant programme 
pour autoriser le paiement d'un montant de 
paiement sur la base d'un compte exterieur de 
carte de credit ou d'un compte exterieur de de- so 
pot a vue disposant d'un credit suffisant ou de 
fonds suffisants ; 



2. Systeme de paiement base sur un reseau informa- 
tique selon la revendication 1, dans lequel I'abrege 
est constitue par I'ordre de paiement entier 

3. Systeme de paiement base sur un reseau informa- 
tique selon la revendication 1 , dans lequel I'abrege 
est une fonction des parties constitutives de I'ordre 
de paiement. 



chacun des ordinateurs clients (70,71), etant 
programme pour etablir un ordre de paiement 55 
specifiant un montant de paiement a transferer 
d'un expediteur a un beneficiaire, un mot cree, 
un identificateur ou une information de compte 



Systeme de paiement base sur un reseau informa- 
tique selon I'une quelconque des revendications 1 
a 3, dans lequel I'ordre de paiement comprend une 
adresse de livraison, et dans lequel I'ordinateur de 
paiement (72) est programme pour faire verifier 
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I'adresse de livraison dans une base de donnees 
d'adresses de livraison autorisees de I'expediteur. 

5. Systeme de paiement base sur un reseau informa- 
tique selon I'une quelconque des revendications 5 
precedentes, dans lequel Pordinateur de paiement 
(72) est programme pour determiner au moins une 
adresse de livraison autorisee de I'expediteur, et 
dans lequel le message d'autorisation d'ordre de 
paiement comprend la au moins une adresse de li- 10 
vraison autorisee. 

6. Systeme de paiement base sur un reseau informa- 
tique selon Tune quelconque des revendications 
precedentes, dans lequel le message d'autorisation 15 
d'ordre de paiement comprend un authentificateur. 

7. Systeme de paiement base sur un reseau informa- 
tique selon I'une quelconque des revendications 
precedentes, dans lequel I'ordinateur client (70,71 ) *o 
est programme pour produire la signature numen- 
que en utilisant un dispositif exterieur, et dans le- 
quel I'ordinateur de paiement (72) est programme 
pour verifier que la signature numerique a ete creee 

en utilisant le dispositif exterieur. 25 

8. Proceed d'utilisation d'un systeme de paiement ba- 
se sur un reseau informatique (300) comprenant 
unepluralite d'ordinateurs clients (70, 71), au moins 

un ordinateur de paiement (72) relies ensemble par 30 
un reseau public de communications commute par 
paquets (69), et un reseau d'autorisation financiere 
exterieur au reseau public de communications com- 
mute par paquets : comprenant les operations 
consistant : 35 

a etablir a Tun des ordinateurs clients un ordre 
de paiement (79) specifiant un montant de 
paiement a transferer d'un expediteur a un be- 
neficiaire, un mot cree, un identificateur ou une *o 
information de compte de I'expediteur, et un 
identificateur ou une information de compte du 
beneficiaire, a signer (80) I'ordre de paiement 
par une signature numerique d'un abrege de 
I'ordre de paiement, la signature numerique 45 
authentifiant I'expediteur de I'ordre de paie- 
ment et etant informatisee sur la base d'une cle 
secrete, et a faire transmettre (81) Pordre de 
paiement et la signature numerique a I'ordina- 
teur de paiement sur le reseau public de com- so 
munications commute par paquets (69), 

en reponse a la reception de Pordre de paie- 
ment et de la signature numerique par I'ordina- 
teur de paiement, a verifier (82) que I'ordre de 55 
paiement provient de I'expediteur de Pordre de 
paiement sur la base de la signature numerique 
recue, a verifier une repetition (84) pour s'as- 



surer que I'expediteur de I'ordre de paiement 
n'avait pas presents anterieurement un ordre 
de paiement avec le meme mot cree, a faire 
transmettre (86) un message dans le reseau 
d'autorisation financiere, afin de verifier que 
I'expediteur dispose de fonds ou d'un credit ap- 
propries, 

le reseau d'autorisation financiere autorise le 
paiement du montant de paiement sur la base 
d'une compte exterieur de carte de credit ou 
d'un compte exterieur de depot a vue disposant 
d'un credit ou de fonds suffisants ; 

a recevoir (87), a Pordinateur de paiement, une 
autorisation de la part du reseau d'autorisation 
financiere en reponse au message, a transmet- 
tre un message d'autorisation d'ordre de paie- 
ment (90) depuis I'ordinateur de paiement a 
I'ordinateur client sur le reseau public de com- 
munications commute par paquets, a faire en- 
registrer dans une base de donnees de regle- 
ment (74) Pinformation appartenant a I'ordre de 
paiement et a Pautorisation, et a faire transferer 
par un reseau de systeme financier exterieur, 
au reseau public de communications commute 
par paquets, des fonds depuis I'expediteur vers 
le beneficiaire sous la condition de la reception 
par I'ordinateur de paiement de Pautorisation 
provenant du reseau d'autorisation financiere, 
et 

a recevoir a I'ordinateur client le message 
d'autorisation d'ordre de paiement. 

9. Proc6de selon la revendication 8, selon lequel 
Pabrege est constitue par i'ordre de paiement entier. 

10. Procede selon la revendication 8, selon lequel 
I'abrege est fonction des parties constitutives de 
I'ordre de paiement. 
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New York Times Headlines 



SHUTTLE HUBBLE (Houston)- Arriving for a house call 357 miles above Earth, the 
astronauts of the space shuttle Endeavor on Saturday reached out with a 
mechanical grappling arm and easily snared the Hubble space telescope and 
prepared to treat the crippled spacecraft in five days of the most 
complex orbital repairs yet attempted. 
By John Noble Wilford 

$1.00 5 



HEALTH-ALLIANCE (Washingcon)- If the Clinton health plan becomes law, ti will put 
a new institution into the lives of most Americans: the health alliance. Almost 
no other aspect of the plan is so little understood or so radically different 
from the status quo. By Robin Toner. 

$0.75 • 



GAMBLING {Las Vegas)- The newest perspeccive on Che booming national industry 
of legalized gambling is now open for business: futuristic virtual-reality 
rides to soothe the losers' souls, just up the theme park escalator from 
acres of the latest video slot machines. By Francis x. Clines. 

50.75 7 
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TROUBLED HUBBLE SPACE TELESCOPE 
PULLED IN BY SHUTTLE FOR REPAIRS 

By JOHN NOBLE WXLFORD 

The New York Times (Copyright 1993 The New York Times) 

priority: Urgent 

date: 12-04-93 1712EST 

catagory: Domestic 

subject: BC SHUTTLE HUBBLE ART 

HOUSTON- Arriving for a house call at 357 miles above Earth,the astronauts 
of the space shuttle Endeavor reached out Saturday with a mechanical 
grappling arm and easily snared the Hubble telescope. 

The orbital retrieval paves the way for the shuttle's astronauts to treat 
the crippledspacecraf t in five days of the most complex orbital repairs 
yet attempted. 

'Houston, Endeavorhas afirm handshake with mr. Hubble'e telescope," Col. 
Richard D. Coveyof the Air Force, the shuttle commander, radioed to 
Mission Control in Houston after the robotic arm had grasped the 1.6 
billion telescope. 

The shuttle's successful rendezvous with the orbiting telescope was the 
firsc major step in a mission that could be fateful to both astronomy and 
NASA 

Installing new mirrors to overcome Hubble's blurred visionwill return the 
telescope to its full abilities, giving the astronomers a view almost to 
the edge of the universe. And such a highly visible success could boost 
the space agency's reputation at a time it is seeking support for building 
an international space station 

Once the 12.5-ton telescope was securely berthed in the oper cargo bay 
Saturday morning, it was ready for the astronauts to begin the first of 
their five space walks early Sunday morning 

The schedule calls for Dr. Musgrave and Dr. Jeffrey A. Hoffman to replace 
failed gyroscopes, two electronic control units and some fuses. 
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39 



1. Dec. 2 1993 14;32 (78 lines] $1.00' " 45 
In •* Dangerous Women,' Debra Winger sinks deeply Into the drab role of 
Martha Horgan, a sheltered innocent living in a small California town. 

2. Dec. 2 1993 14:23 {60 lines? $1.00 40 
•Deception* is a fabulously farfetched story about the string of suprises 
that leads Bessie Paro (Andie MacDowell) all over the world. 

3. Nov. 26 1993 19:43 [49 lines) $1.00 41 

■Twenty Bucks" follows a $20 dollar bill from the moment it's dispensed by an 
automatic teller machine to its destruction months later. Along the way it 
passes through the hands of dorens of individuals from all walks of life. 

4. Nov. 23 1993 18;46 [4B lines) $1.00 12 

I" A Perfect World, - a drama, is rated PG-13 for language and violence. It 
received 3 and one-half stars out of 4.) 

Clint Eastwood and Kevin costner represent the best of Hollywood's stars who 
entertain without sacrificing artistic integrity. In *A Perfect World,' their 
reputations remain intact. 

5. Nov. 23 1993 18:46 [53 lines] $1.00 43 
(•GEORGE BALANCHINE'S -NUTCRACKER," a dance film, is rated G. It received 2 
stars out of 4.) 

A straightforward record of the annual Christmas show staged by the 
New York City Ballet, "George Balanchine's 'Nutcracker/' would have gone 
directly to TV if not for the participation of 

6. Nov. 23 1993 18:46 [60 lines] $1.00 44 

(•WE'RE BACK! A DINOSAUR'S STORY," an animated feature, is rated G. It received 
2 starB out of 4.) 

Kids won't even understand the best joke in the animated "We're Back! A 
Dinosaur's story.' It has to do with a godlike line- and space-traveling 
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A DANGEROUS WOMAN 

By JANET MASLIN 

The New York Times (Copyright 1993 The new York Times 

priority: Regular 

date: 12-02-93 1432EST 

category: Entertainment and Culture 

subject: BC WOKEN FILM REVIEW 



In *A Dangerous Women,' Debra winger sinks deeply inti the drab role of 
Martha Horgan. a shelteredinnocent living in a small California town. 

Characters like martha have a way attracting the storyteller's interst at a 
very precise point in their lives. It is the moment just before the 
character's peaceful existence is ruptured by some seismic force like sex 
or death or a symbolic coming of age. 

"A Dangerous Women* is soap opera enough to churn up all three. 

With Ms. Winger's eerily convincing performance at it's centerpiece, the film 
creates a world of sexual chicanery that would do any television series 
proud. 

Martha is taken care of by aunt Frances (Barbara Hershey), a rich, beautiful 
widow involved in an extramarital affair with a state assemblyman 
(John Terry). That liaisonstarts off the film with a suitable bang, as the 
assembly's wife (laurie metcalf) drunkenly drives her car into the widow's 
front porch as a means of registering her irritation. 

Martha, a fragile creature in a girlish nightgown and thick glasses, 
watches this outburst in bewildered horror. But the film intends it as a 
harbringer of Martha's own act of violence, which is already in the 
works and will serve as 
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